表记|下图_阿里Seata新版本终于解决了TCC模式的幂等悬挂和空回滚问题

篇首语：本文由编程笔记#小编为大家整理，主要介绍了阿里 Seata 新版本终于解决了 TCC 模式的幂等悬挂和空回滚问题相关的知识，希望对你有一定的参考价值。

大家好&＃xff0c;我是君哥。

今天来聊一聊阿里巴巴 Seata 新版本&＃xff08;1.5.1&＃xff09;是怎么解决 TCC 模式下的幂等、悬挂和空回滚问题的。

TCC 回顾

TCC 模式是最经典的分布式事务解决方案&＃xff0c;它将分布式事务分为两个阶段来执行&＃xff0c;try 阶段对每个分支事务进行预留资源&＃xff0c;如果所有分支事务都预留资源成功&＃xff0c;则进入 commit 阶段提交全局事务&＃xff0c;如果有一个节点预留资源失败则进入 cancel 阶段回滚全局事务。

以传统的订单、库存、账户服务为例&＃xff0c;在 try 阶段尝试预留资源&＃xff0c;插入订单、扣减库存、扣减金额&＃xff0c;这三个服务都是要提交本地事务的&＃xff0c;这里可以把资源转入中间表。在 commit 阶段&＃xff0c;再把 try 阶段预留的资源转入最终表。而在 cancel 阶段&＃xff0c;把 try 阶段预留的资源进行释放&＃xff0c;比如把账户金额返回给客户的账户。

注意&＃xff1a;try 阶段必须是要提交本地事务的&＃xff0c;比如扣减订单金额&＃xff0c;必须把钱从客户账户扣掉&＃xff0c;如果不扣掉&＃xff0c;在 commit 阶段客户账户钱不够了&＃xff0c;就会出问题。

try-commit

try 阶段首先进行预留资源&＃xff0c;然后在 commit 阶段扣除资源。如下图&＃xff1a;

try-cancel

try 阶段首先进行预留资源&＃xff0c;预留资源时扣减库存失败导致全局事务回滚&＃xff0c;在 cancel 阶段释放资源。如下图&＃xff1a;

TCC 优势

TCC 模式最大的优势是效率高。TCC 模式在 try 阶段的锁定资源并不是真正意义上的锁定&＃xff0c;而是真实提交了本地事务&＃xff0c;将资源预留到中间态&＃xff0c;并不需要阻塞等待&＃xff0c;因此效率比其他模式要高。

同时 TCC 模式还可以进行如下优化&＃xff1a;

异步提交

try 阶段成功后&＃xff0c;不立即进入 confirm/cancel 阶段&＃xff0c;而是认为全局事务已经结束了&＃xff0c;启动定时任务来异步执行 confirm/cancel&＃xff0c;扣减或释放资源&＃xff0c;这样会有很大的性能提升。

同库模式

TCC 模式中有三个角色&＃xff1a;

• TM&＃xff1a;管理全局事务&＃xff0c;包括开启全局事务&＃xff0c;提交/回滚全局事务&＃xff1b;
• RM&＃xff1a;管理分支事务&＃xff1b;
• TC: 管理全局事务和分支事务的状态。

下图来自 Seata 官网&＃xff1a;

TM 开启全局事务时&＃xff0c;RM 需要向 TC 发送注册消息&＃xff0c;TC 保存分支事务的状态。TM 请求提交或回滚时&＃xff0c;TC 需要向 RM 发送提交或回滚消息。这样包含两个个分支事务的分布式事务中&＃xff0c;TC 和 RM 之间有四次 RPC。

优化后的流程如下图&＃xff1a;

TC 保存全局事务的状态。TM 开启全局事务时&＃xff0c;RM 不再需要向 TC 发送注册消息&＃xff0c;而是把分支事务状态保存在了本地。TM 向 TC 发送提交或回滚消息后&＃xff0c;RM 异步线程首先查出本地保存的未提交分支事务&＃xff0c;然后向 TC 发送消息获取&＃xff08;本地分支事务所在的&＃xff09;全局事务状态&＃xff0c;以决定是提交还是回滚本地事务。

这样优化后&＃xff0c;RPC 次数减少了 50%&＃xff0c;性能大幅提升。

RM 代码示例

以库存服务为例&＃xff0c;RM 库存服务接口代码如下&＃xff1a;

&＃64;LocalTCC
public interface StorageService
/**
* 扣减库存
* &＃64;param xid 全局xid
* &＃64;param productId 产品id
* &＃64;param count 数量
* &＃64;return
*/
&＃64;TwoPhaseBusinessAction(name &＃61; "storageApi", commitMethod &＃61; "commit", rollbackMethod &＃61; "rollback", useTCCFence &＃61; true)
boolean decrease(String xid, Long productId, Integer count);
/**
* 提交事务
* &＃64;param actionContext
* &＃64;return
*/
boolean commit(BusinessActionContext actionContext);
/**
* 回滚事务
* &＃64;param actionContext
* &＃64;return
*/
boolean rollback(BusinessActionContext actionContext);


通过 &＃64;LocalTCC 这个注解&＃xff0c;RM 初始化的时候会向 TC 注册一个分支事务。在 try 阶段的方法&＃xff08;decrease方法&＃xff09;上有一个 &＃64;TwoPhaseBusinessAction 注解&＃xff0c;这里定义了分支事务的 resourceId&＃xff0c;commit 方法和 cancel 方法&＃xff0c;useTCCFence 这个属性下一节再讲。

TCC 存在问题

TCC 模式中存在的三大问题是幂等、悬挂和空回滚。在 Seata1.5.1 版本中&＃xff0c;增加了一张事务控制表&＃xff0c;表名是 tcc_fence_log 来解决这个问题。而在上一节 &＃64;TwoPhaseBusinessAction 注解中提到的属性 useTCCFence 就是来指定是否开启这个机制&＃xff0c;这个属性值默认是 false。

tcc_fence_log 建表语句如下&＃xff08;mysql 语法&＃xff09;&＃xff1a;

CREATE TABLE IF NOT EXISTS &＃96;tcc_fence_log&＃96;
(
&＃96;xid&＃96; VARCHAR(128) NOT NULL COMMENT &＃39;global id&＃39;,
&＃96;branch_id&＃96; BIGINT NOT NULL COMMENT &＃39;branch id&＃39;,
&＃96;action_name&＃96; VARCHAR(64) NOT NULL COMMENT &＃39;action name&＃39;,
&＃96;status&＃96; TINYINT NOT NULL COMMENT &＃39;status(tried:1;committed:2;rollbacked:3;suspended:4)&＃39;,
&＃96;gmt_create&＃96; DATETIME(3) NOT NULL COMMENT &＃39;create time&＃39;,
&＃96;gmt_modified&＃96; DATETIME(3) NOT NULL COMMENT &＃39;update time&＃39;,
PRIMARY KEY (&＃96;xid&＃96;, &＃96;branch_id&＃96;),
KEY &＃96;idx_gmt_modified&＃96; (&＃96;gmt_modified&＃96;),
KEY &＃96;idx_status&＃96; (&＃96;status&＃96;)
) ENGINE &＃61; InnoDB
DEFAULT CHARSET &＃61; utf8mb4;

幂等

在 commit/cancel 阶段&＃xff0c;因为 TC 没有收到分支事务的响应&＃xff0c;需要进行重试&＃xff0c;这就要分支事务支持幂等。

我们看一下新版本是怎么解决的。下面的代码在 TCCResourceManager 类&＃xff1a;

&＃64;Override
public BranchStatus branchCommit(BranchType branchType, String xid, long branchId, String resourceId,
String applicationData) throws TransactionException
TCCResource tccResource &＃61; (TCCResource)tccResourceCache.get(resourceId);
//省略判断
Object targetTCCBean &＃61; tccResource.getTargetBean();
Method commitMethod &＃61; tccResource.getCommitMethod();
//省略判断
try
//BusinessActionContext
BusinessActionContext businessActionContext &＃61; getBusinessActionContext(xid, branchId, resourceId,
applicationData);
Object[] args &＃61; this.getTwoPhaseCommitArgs(tccResource, businessActionContext);
Object ret;
boolean result;
//注解 useTCCFence 属性是否设置为 true
if (Boolean.TRUE.equals(businessActionContext.getActionContext(Constants.USE_TCC_FENCE)))
try
result &＃61; TCCFenceHandler.commitFence(commitMethod, targetTCCBean, xid, branchId, args);
catch (SkipCallbackWrapperException | UndeclaredThrowableException e)
throw e.getCause();

else
//省略逻辑

LOGGER.info("TCC resource commit result : , xid: , branchId: , resourceId: ", result, xid, branchId, resourceId);
return result ? BranchStatus.PhaseTwo_Committed : BranchStatus.PhaseTwo_CommitFailed_Retryable;
catch (Throwable t)
//省略
return BranchStatus.PhaseTwo_CommitFailed_Retryable;



上面的代码可以看到&＃xff0c;执行分支事务提交方法时&＃xff0c;首先判断 useTCCFence 属性是否为 true&＃xff0c;如果为 true&＃xff0c;则走 TCCFenceHandler 类中的 commitFence 逻辑&＃xff0c;否则走普通提交逻辑。

TCCFenceHandler 类中的 commitFence 方法调用了 TCCFenceHandler 类的 commitFence 方法&＃xff0c;代码如下&＃xff1a;

public static boolean commitFence(Method commitMethod, Object targetTCCBean,
String xid, Long branchId, Object[] args)
return transactionTemplate.execute(status ->
try
Connection conn &＃61; DataSourceUtils.getConnection(dataSource);
TCCFenceDO tccFenceDO &＃61; TCC_FENCE_DAO.queryTCCFenceDO(conn, xid, branchId);
if (tccFenceDO &＃61;&＃61; null)
throw new TCCFenceException(String.format("TCC fence record not exists, commit fence method failed. xid&＃61; %s, branchId&＃61; %s", xid, branchId),
FrameworkErrorCode.RecordAlreadyExists);

if (TCCFenceConstant.STATUS_COMMITTED &＃61;&＃61; tccFenceDO.getStatus())
LOGGER.info("Branch transaction has already committed before. idempotency rejected. xid: , branchId: , status: ", xid, branchId, tccFenceDO.getStatus());
return true;

if (TCCFenceConstant.STATUS_ROLLBACKED &＃61;&＃61; tccFenceDO.getStatus() || TCCFenceConstant.STATUS_SUSPENDED &＃61;&＃61; tccFenceDO.getStatus())
if (LOGGER.isWarnEnabled())
LOGGER.warn("Branch transaction status is unexpected. xid: , branchId: , status: ", xid, branchId, tccFenceDO.getStatus());

return false;

return updateStatusAndInvokeTargetMethod(conn, commitMethod, targetTCCBean, xid, branchId, TCCFenceConstant.STATUS_COMMITTED, status, args);
catch (Throwable t)
status.setRollbackOnly();
throw new SkipCallbackWrapperException(t);

);


从代码中可以看到&＃xff0c;提交事务时首先会判断 tcc_fence_log 表中是否已经有记录&＃xff0c;如果有记录&＃xff0c;则判断事务执行状态并返回。这样如果判断到事务的状态已经是 STATUS_COMMITTED&＃xff0c;就不会再次提交&＃xff0c;保证了幂等。如果 tcc_fence_log 表中没有记录&＃xff0c;则插入一条记录&＃xff0c;供后面重试时判断。

Rollback 的逻辑跟 commit 类似&＃xff0c;逻辑在类 TCCFenceHandler 的 rollbackFence 方法。

空回滚

如下图&＃xff0c;账户服务是两个节点的集群&＃xff0c;在 try 阶段账户服务 1 这个节点发生了故障&＃xff0c;try 阶段在不考虑重试的情况下&＃xff0c;全局事务必须要走向结束状态&＃xff0c;这样就需要在账户服务上执行一次 cancel 操作&＃xff0c;这样就空跑了一次回滚操作。

Seata 的解决方案是在 try 阶段 往 tcc_fence_log 表插入一条记录&＃xff0c;status 字段值是 STATUS_TRIED&＃xff0c;在 Rollback 阶段判断记录是否存在&＃xff0c;如果不存在&＃xff0c;则不执行回滚操作。代码如下&＃xff1a;

//TCCFenceHandler 类
public static Object prepareFence(String xid, Long branchId, String actionName, Callback targetCallback)
return transactionTemplate.execute(status ->
try
Connection conn &＃61; DataSourceUtils.getConnection(dataSource);
boolean result &＃61; insertTCCFenceLog(conn, xid, branchId, actionName, TCCFenceConstant.STATUS_TRIED);
LOGGER.info("TCC fence prepare result: . xid: , branchId: ", result, xid, branchId);
if (result)
return targetCallback.execute();
else
throw new TCCFenceException(String.format("Insert tcc fence record error, prepare fence failed. xid&＃61; %s, branchId&＃61; %s", xid, branchId),
FrameworkErrorCode.InsertRecordError);

catch (TCCFenceException e)
//省略
catch (Throwable t)
//省略

);


在 Rollback 阶段的处理逻辑如下:

//TCCFenceHandler 类
public static boolean rollbackFence(Method rollbackMethod, Object targetTCCBean,
String xid, Long branchId, Object[] args, String actionName)
return transactionTemplate.execute(status ->
try
Connection conn &＃61; DataSourceUtils.getConnection(dataSource);
TCCFenceDO tccFenceDO &＃61; TCC_FENCE_DAO.queryTCCFenceDO(conn, xid, branchId);
// non_rollback
if (tccFenceDO &＃61;&＃61; null)
//不执行回滚逻辑
return true;
else
if (TCCFenceConstant.STATUS_ROLLBACKED &＃61;&＃61; tccFenceDO.getStatus() || TCCFenceConstant.STATUS_SUSPENDED &＃61;&＃61; tccFenceDO.getStatus())
LOGGER.info("Branch transaction had already rollbacked before, idempotency rejected. xid: , branchId: , status: ", xid, branchId, tccFenceDO.getStatus());
return true;

if (TCCFenceConstant.STATUS_COMMITTED &＃61;&＃61; tccFenceDO.getStatus())
if (LOGGER.isWarnEnabled())
LOGGER.warn("Branch transaction status is unexpected. xid: , branchId: , status: ", xid, branchId, tccFenceDO.getStatus());

return false;


return updateStatusAndInvokeTargetMethod(conn, rollbackMethod, targetTCCBean, xid, branchId, TCCFenceConstant.STATUS_ROLLBACKED, status, args);
catch (Throwable t)
status.setRollbackOnly();
throw new SkipCallbackWrapperException(t);

);


updateStatusAndInvokeTargetMethod 方法执行的 sql 如下&＃xff1a;

update tcc_fence_log set status &＃61; ?, gmt_modified &＃61; ?
where xid &＃61; ? and branch_id &＃61; ? and status &＃61; ? ;

可见就是把 tcc_fence_log 表记录的 status 字段值从 STATUS_TRIED 改为 STATUS_ROLLBACKED&＃xff0c;如果更新成功&＃xff0c;就执行回滚逻辑。

悬挂

悬挂是指因为网络问题&＃xff0c;RM 开始没有收到 try 指令&＃xff0c;但是执行了 Rollback 后 RM 又收到了 try 指令并且预留资源成功&＃xff0c;这时全局事务已经结束&＃xff0c;最终导致预留的资源不能释放。如下图&＃xff1a;

Seata 解决这个问题的方法是执行 Rollback 方法时先判断 tcc_fence_log 是否存在当前 xid 的记录&＃xff0c;如果没有则向 tcc_fence_log 表插入一条记录&＃xff0c;状态是 STATUS_SUSPENDED&＃xff0c;并且不再执行回滚操作。代码如下&＃xff1a;

public static boolean rollbackFence(Method rollbackMethod, Object targetTCCBean,
String xid, Long branchId, Object[] args, String actionName)
return transactionTemplate.execute(status ->
try
Connection conn &＃61; DataSourceUtils.getConnection(dataSource);
TCCFenceDO tccFenceDO &＃61; TCC_FENCE_DAO.queryTCCFenceDO(conn, xid, branchId);
// non_rollback
if (tccFenceDO &＃61;&＃61; null)
//插入防悬挂记录
boolean result &＃61; insertTCCFenceLog(conn, xid, branchId, actionName, TCCFenceConstant.STATUS_SUSPENDED);
//省略逻辑
return true;
else
//省略逻辑

return updateStatusAndInvokeTargetMethod(conn, rollbackMethod, targetTCCBean, xid, branchId, TCCFenceConstant.STATUS_ROLLBACKED, status, args);
catch (Throwable t)
//省略逻辑

);


而后面执行 try 阶段方法时首先会向 tcc_fence_log 表插入一条当前 xid 的记录&＃xff0c;这样就造成了主键冲突。代码如下&＃xff1a;

//TCCFenceHandler 类
public static Object prepareFence(String xid, Long branchId, String actionName, Callback targetCallback)
return transactionTemplate.execute(status ->
try
Connection conn &＃61; DataSourceUtils.getConnection(dataSource);
boolean result &＃61; insertTCCFenceLog(conn, xid, branchId, actionName, TCCFenceConstant.STATUS_TRIED);
//省略逻辑
catch (TCCFenceException e)
if (e.getErrcode() &＃61;&＃61; FrameworkErrorCode.DuplicateKeyException)
LOGGER.error("Branch transaction has already rollbacked before,prepare fence failed. xid&＃61; ,branchId &＃61; ", xid, branchId);
addToLogCleanQueue(xid, branchId);

status.setRollbackOnly();
throw new SkipCallbackWrapperException(e);
catch (Throwable t)
//省略

);


注意&＃xff1a;queryTCCFenceDO 方法 sql 中使用了 for update&＃xff0c;这样就不用担心 Rollback 方法中获取不到 tcc_fence_log 表记录而无法判断 try 阶段本地事务的执行结果了。

总结

TCC 模式是分布式事务使用最多的模式&＃xff0c;但是幂等、悬挂和空回滚一直是 TCC 模式需要考虑的问题&＃xff0c;Seata 框架在 1.5.1 版本完美解决了这些问题。

对 tcc_fence_log 表的操作也需要考虑事务的控制&＃xff0c;Seata 使用了代理数据源&＃xff0c;使 tcc_fence_log 表操作和 RM 业务操作在同一个本地事务中执行&＃xff0c;这样就能保证本地操作和对 tcc_fence_log 的操作同时成功或失败。

作者&＃xff1a;朱晋君

原文链接

本文为阿里云原创内容&＃xff0c;未经允许不得转载